ソフトウェア部品表 (SBOM) について: SBOM がサイバーセキュリティに不可欠な理由

SBOM は、下記を確保する上で重要な資産です。

• 規制コンプライアンス

• 古いソフトウェアパッケージと OSS アップデートとの間の互換性

• ソフトウェアサプライチェーンに対する攻撃における顧客の保護

• ソフトウェアとライセンスを伴う合併におけるセキュリティ保護

SBOM と CBOM の相違点

2018 年サイバーセキュリティ部品表 (CBOM) は、1 つの大統領令の中でソフトウェアとハードウェアの両方を規定しています。SBOM は、コード内のソフトウェアコンポーネント、バージョン、パッチ、ライセンス、更新、変更の履歴だけを文書化します。

サイバーセキュリティを確保する上で SBOM が重要な理由

ソフトウェアサプライチェーンを標的とするサイバー攻撃が増加しています。これらの攻撃の半分以上は、既知のサイバー犯罪グループによる APT (advanced persistent threat ) 攻撃です。その目的は、システムに対するユーザーとサプライヤーの信用を逆手に取って悪用することです。

サプライチェーンが攻撃を受けやすい理由は、サイバーインシデントに関する透明性の低さです。場合によっては、開発者が潜在的な脆弱性に気づかず、その結果、ユーザーにも脆弱性が生じるおそれがあります。オープンソースライブラリは、他のソフトウェアコンポーネントに依存しています。Log4Shell 脆弱性のようなケースは、コンポーネント (この場合はロギングライブラリ) が直接的なソフトウェア依存関係ではなく、むしろ他のコンポーネントからの推移的な依存関係であるため、多くの開発者は確認を怠りがちです。

開発チームがすでにアプリケーションセキュリティの必要性を認識していても、SBOM はソフトウェアサプライチェーンと潜在的な脆弱性をさらに可視化します。ユーザーがソフトウェア製品のどこに脆弱性が潜んでいるかを把握し、特にオープンソースの場合はソフトウェアコンポーネントを理解すれば、潜在的な攻撃を検出して対処するセキュリティツールを適切に導入できるようになります。

サイバー攻撃が発生した場合、SBOM を使用すれば、脆弱なコンポーネントが存在するソフトウェアや、存在するリスクの種類を特定できます。これにより、ユーザーは開発者と協力してパッチやその他の緩和策を講じることができます。

SBOM に関する大統領令 14028

Log4Shell 以前にも、SolarWinds のサプライチェーン攻撃や Apache Struts に関連した Equifax 事件などのサイバーインシデントが発生しており、政府機関や大企業など一般企業の重要インフラが抱える脆弱性が明らかになっています。また、どの組織もソフトウェアサプライチェーンに強く依存していること、1 つの脆弱性が悪用されるとその影響が広範囲に連鎖する可能性があることも示されていました。

大統領令 14028 は、アメリカ国立標準技術研究所 (NIST)、国家安全保障局 (NSA)、行政管理予算局 (OMB)、サイバーセキュリティ・社会基盤安全保障庁 (CISA)、国家情報長官 (DNI) などの政府機関に対し、ソフトウェアサプライチェーンにおけるセキュリティを改善する規格とベストプラクティスを策定するよう求めています。ガイドラインには、下記の内容が盛り込まれています。

• ソフトウェアセキュリティの評価基準 

• 開発者とサプライヤー自身のセキュリティ対策に関する評価基準

• セキュリティ対策の遵守を実証する、革新的なツールや手法

2022 年 2 月までに、NIST とその他の機関がソフトウェアサプライチェーンのベストプラクティスに関するガイドラインを発表する予定ですが、それまでの間は、現時点で実施可能なサプライチェーンセキュリティのベストプラクティス一覧を参照してください。

ソフトウェア部品表を使用するべき状況

ソフトウェアコンポーネントが新しくリリースされるたびに、新しい SBOM を作成する必要があります。同様に、コンポーネントを変更するたびに、その変更に合わせて SBOM を更新する必要があります。

NTIA が定める SBOM のベースラインには、下記の情報を含める必要があります。

• 作成者名

• サプライヤー名

• コンポーネント名

• コンポーネントのハッシュ値

• バージョン

• 識別子

• 関係

ベースライン要件を満たすため、SBOM 規格は、複数のツールで使用できる共通フォーマットの提供を目的として開発されました。これらの規格は、下記のとおりです。

• SPDX: Software Product Data Exchange は、ソフトウェアパッケージのコンポーネント、ライセンス、セキュリティ情報を伝達するためのオープンスタンダードです。SPDX は複数のサービスを標準化し、それぞれが独自の SBOM を使用します。

• SWID: ソフトウェア識別タグは、ライフサイクルを定義する規格です。タグは、ソフトウェアのインストールプロセスの一環としてエンドポイントに追加されます。タグには 4 種類あり、プレインストール段階で使用されるコーパスタグ、製品名を提供し、グローバルな一意の識別子とみなされるプライマリタグ、ソフトウェアに適用されたパッチを記述するパッチタグ、関連情報を追加する補足タグです。

• OWASP Cyclone DX: サプライチェーンのコンポーネント分析とアプリケーションセキュリティに使用される、軽量の SBOM 規格です。

• VEX: Vulnerability Exploitability Exchange は、製品に関する追加情報を提供し、特にコンポーネントで発見された脆弱性に対して、修正策を推奨します。

SBOM とソフトウェアの完全性

SBOM は、ソフトウェアサプライチェーンの完全性を判断し、収集した情報に基づいてリスク評価ができるよう構成されています。SBOM は、サプライチェーン内のソフトウェアコンポーネントのインベントリを全般的に評価します。しかし、規格が適用されると、SBOM は OSS のコンプライアンス基準に対応することになります。たとえば、SPDX 規格はこれらのコンポーネントのライセンスを識別し、コンプライアンスの確保に使用されます。

SLSA (Supply Chain Levels for Software Artifacts) は、サプライチェーンにおけるオープンソースソフトウェアの成果物の完全性を維持することを目的とした、一連の規格と管理策です。Google が導入したもので、NIST のサプライチェーンセキュリティに関する推奨事項に対応しています。SLSA は、SBOM の機能を補完し、開発プロセスで使用されるオープンソースソフトウェアの大部分を保護します。

SBOM を使用した依存関係と脆弱性の検出

SBOM の主なセキュリティ上の目的は、ソフトウェアサプライチェーン全体の脆弱性とリスクを特定することです。脆弱性に関するデータは、コンポーネントの追加や変更によって常に変化し、新たな悪用の可能性が生じます。SBOM は基本的に静的であるため、SBOM の作成に使用されるデータは常に変化と発展を続けています。

SBOM は、脆弱性分析を行い、開発者が依存関係を更新してリスクを軽減しているかどうかを確認できる、ソフトウェアユーザー向けのツールです。しかし、すべての脆弱性が同程度のリスクをもたらすわけではなく、まったくリスクが生じない場合もあります。この問題に対処するため、NTIA は次のような 2 つの対策を提案しています。

• 開発/供給側で、脆弱性の影響、具体的にはソフトウェアの特定の領域に影響を及ぼすかどうかの判断を必ず行う。

• 脆弱性に関する情報は、SBOM のデータを通じて、その脆弱性がリスクを増加させないことを検証しながら、必ず十分に伝える。

ソフトウェアサプライチェーンセキュリティを確保する SBOM

SBOM は、次のような方法でソフトウェアのサプライチェーンのセキュリティを高めます。

• システムの関係を含む、ソフトウェア製品全体の可視性を向上

• 脆弱性に関する情報共有

• 開発者からユーザーまで、サプライチェーン全体のコミュニケーションを改善し、セキュリティリスクの発見を容易化

• コンプライアンス基準と監査に関する詳細な記録

SBOM は、ソフトウェアのサプライチェーン全体で保護とリスク検出を強化する、拡張型のセキュリティツールです。SBOM にソフトウェア内の各コンポーネントに関するより正確で詳細な情報が記載されることで、ソフトウェア製造ライフサイクルの早い段階で脆弱性を発見できるようになり、さらには問題が発生する前に対策を講じられるようになります。

Snyk は、SBOM の構築プロセスを自動化し、企業が使用するオープンソースコンポーネントと依存関係を追跡しやすくしました。また、Snyk はこれらの各コンポーネントをスキャンして潜在的な脆弱性を発見し、それに対する実用的な修正案を提示することもできます。